Subject: RE: Electronic AP for DLSw Multicast

From: Paul Brittain <[email-masked]>
Date: Mon, 23 Sep 1996 15:28:12 +0100

Dave et al.

Sorry for the delay in this reply - I have been on vacation (Hint:
Judging by the amount of rain there last week, 1996 may not be the
greatest vintage for wines from Southern France!).  

The CP-draft will be out within 2 weeks of AP on the multicast proposal
(probably on 10/21 if we get AP on 10/11), which would give people at
least one week to read it before the AIW 12 on 11/4.  If AP is delayed,
this time will be reduced.

Paul.
>----------
>From:
>	David.Bryant/HQ/[email-masked][SMTP:David.Bryant/HQ/[email-masked]
>gh.ibm.com]
>Sent: 	20 September 1996 01:51
>To: 	Paul Brittain
>Subject: 	Electronic AP for DLSw Multicast
>
>Sorry for the delay in responding guys... some long needed
>vacation and work crisises kept me away.
>
>Sounds like I'm going to have to put out a new version of 
>the document to address some of the (very valid)concerns brought
>up.  So please get me your comments on these proposed changes 
>by 9/25 and I will get a new verision of the spec out by 9/27 
>and will want go AP on it if there are no substantial objections 
>by 10/11.
>
>Here's a list of the issues (as I read them) and responses:
>
>1).  What are we asking AP approval on
>
>I'm asking for AP status on the DLSw Multicast proposal only. 
>The current plan (as discussed at the AIW)is that we will try 
>to gain AP status on DLSw Multicast at AIW 11 (now occurring 
>electronically).  Then Paul Brittan will create a new document
>containing the DLSw Multicast proposal and other approved DLSw 
>changes into a single DLSw Version 1.1 document for CP approval
>at AIW 12 (Nov '96).  This latter item is looking less likely 
>every day.  And, I have not as of yet received any indication 
>from Paul that he will be able to create the DLSw Ver 1.1 spec. 
>in the time necessary to receive CP at AIW 12.  
>
>2). Single Tunnel activation with DLSw Multicast 
>
>You guys are right.  I went into the document and changed the 
>read port to 2067, but didn't look closely enough at what I was 
>doing to realize I need to add clarification text.   It is my 
>intent to say that DLSw Multicast nodes should establish a single 
>TCP connection on 2067.   This still leaves a potential race 
>condition whereby two DLSws bring up connections to 2067 at the 
>same time.   In this case, the DLSw with the higher IP address 
>must tear down it's connection after the capabilities exchange 
>using a new reason code: x'000E' - unnecessary excess connection
>terminated 
>
>This shouldn't create a problem when connecting to down-level 
>(non-multicast) DLSw's because these types of connections must 
>be predefined anyway.  So the DLSw should know to use the RFC 
>1795 method.
>
>Clarifying this will take some text in several places in the 
>document... so it sounds like I'm sending out a new updated 
>version.  Please give me your comments by 9/25, before I bother
>to do so.
>
>3). UDP Packet parsing 
>
>Sounds like there's some concern over the text describing how/when
>to ignore imbedded control vectors. I put this in because that was 
>(and always is) the working assumption in RFC 1795 (and SNA).   
>But it was never documented.  It's purpose with respect to this 
>document is currently not needed, but might be in the future.   
>I figured putting it in now, might help avoid problems or at least 
>establish a way to rule on who implemented correctly in the future.   
>I advise keeping it in, but am ambivalent.   Since it seems 
>to create some level of concern, the easiest thing to do is remove 
>it.  I propose to do that unless someone strongly wants it in 
>(and let's me know prior to 9/25). 
>
>4). NetBIOS transport chart updates
>
>I'm ok with the suggested updates (basically saying unicast vs.
>multicast is an implementation issue based upon whether the sending
>node has cached enough information to determine which is necessary).
>I'm also ok with simply deleting the statement regarding DATAGRAM 
>frames and whether they flow as DATAFRAMEs or DGRMFRAMEs.  This is 
>covered in RFC 1795 and need not be covered in the multicast document. 
>
>5). Vendor Specific UDP packet 
>
>Couple issues here.
>
>5.1). Header length
>
>The header length should be at least 7 and could be higher if the 
>vendor chooses.  I will add text accordingly
>
>5.2). Message type following OUI
>
>I don't think this is necessary.  I think the easier thing to do 
>is to simply strike the statement that AIW standards will 
>use an OUI of zeros.   This way we'll leave AIW standard UDP packet 
>formats to be defined later.   We also potentially save 3 bytes
>on each packet. 
>
>5.3). Clarification text
>
>Sounds like folks want more text clarifying the fields of the
>vendor specific UDP packet header.   I'll do this, but it will 
>be pretty simply now.  I'll add text that the header length is
>always 7 or higher.  I'll remove text regarding AIW standards
>using zeros.   Is there anything else anybody feels I should add?
>
>6). Typos etc.
>
>- I found and agree with all but "Single session TCP connections: 
>section; first paragraph, first sentence... where's the error?
>- "Vendor Specifi Functions over UDP"; second paragraph, first 
>sentence... what second paragraph?
>- change "set of DLSw" to "set of DLSws"... couldn't find, 
>where is this? Found and corrected this under "Unicast UDP 
>Datagrams"
>
>7). DLSw Discovery
>
>That's a seperate topic that I'll leave to those with an interest.
>I suggest this discussion be moved outside the DLSw-scalability Riglet.
>
>Anything else??? 
>
>Regards, Dave
>PS.  Boy will I be glad when this is done!
>
>